【セッションレポート】『バイオハザードヴィレッジゴールドエディション』開発におけるクラウド活用のアプローチ（株式会社カプコン）#CUS-19 #AWSSummit2023

AWSをゲーム開発環境として活用した事例です。ゲーム開発環境の効率化に繋がるようなお話を聞くことが出来ました。

AWS Summit Tokyo 2023

#セッションレポート

やました

2023.04.20

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

皆さんこんにちは。クラスメソッドのやましたです。

2023年4月20日-21日にかけて開催されたAWS Summit Tokyo2023において、AWSをゲーム開発環境として活用した事例セッションがあり、ゲーム開発環境の効率化に繋がるようなお話を聞くことが出来ました。

実際にご登壇された株式会社カプコン伊集院様から掲載許可を頂き、レポートブログをお届けいたします。

伊集院様、この場を借りて、御礼を申し上げます。

（なお、メモを取るのに必死だったため全編テキストとなり、写真はありません。予めご了承ください。）

セッション概要

『バイオハザードヴィレッジゴールドエディション』開発におけるクラウド活用のアプローチ（株式会社カプコン）

カプコンでは AAA タイトル作成における膨大なビルド作業・データ変換作業・パッケージングに加え、マルチプラットフォーム戦略の推進により、同一タイトルでも対応ハードウェアや仕向け地、使用用途などのバリエーションにより数十個のパッケージを同時に作成する必要があり、開発上での大きな負担になっています。

本講演では『バイオハザードヴィレッジゴールドエディション』開発において、上記を解決するために行ったクラウド活用事例やそこで得られた気付き、今後の展望などについてご紹介致します。

※AWS Summitのページから引用

https://aws.amazon.com/jp/summits/tokyo/agenda/

登壇者

伊集院勝さま

株式会社カプコン　基盤技術研究開発部　基盤開発支援室　室長

1993年入社、「ロックマンDASHシリーズ」、「鬼武者2」のメインプログラマ担当
自社開発エンジンのディレクター、PMを経て技術渉外、自社開催イベントの責任者など幅広い業務に携わる
直近では自社技術イベント、カプコンオープンカンファレンスを開催

セッション内容

バイオハザードヴィレッジゴールドエディションとは？
- バイオハザードヴィレッジに追加シナリオや三人称視点モードを追加したタイトル
- 自社開発エンジン「RE ENGINE」を使用している

カプコンの開発事情

今回クラウドを活用することにした動機でもある
カプコンでは2008年からマルチプラットフォーム戦略をとっており、1つのタイトルを複数のプラットフォームで展開している
- PSを2世代、XBOXを2世代、、Windows、Mac、NintendoSwitchで合計7つのプラットフォーム
リージョン対応
- US,EU,ASIA_US…など7つのリージョンにわたる違いが存在する
- 日本におけるCERO Z対応などもリージョンに含んでいる
仕様・用途の違いによる違い
- 仕様：製品、体験版、タイトルアップデート、DLC…
- 用途：マスタ、デバッグ…
その結果、どうなるか？
- カプコンでは製品仕様の違いをSKUと呼んでいるが、SKUが大量に発生する
- 7リージョン×7プラットフォームで28パッケージ
- デバッグパッケージと製品パッケージで2パッケージ
- 合計56パッケージが必要になる
- 全てが同時開発というわけではないにしても開発終盤は51パッケージを同時につくる必要があった

パッケージ作成について

パッケージ作成は以下の流れで進む

ゲーム実行ファイルのビルド
- RE ENGINEではC#で開発したものをC++コードに変換している
アセットのコンバート
- ゲーム内で扱うテクスチャ、メッシュ、シーン情報、シェーダーなどをプラットフォームごとの最適な形に変換する
- SKU間で共有可能だが、言語や地域ごとの専用アセットも存在する
コンバートしたファイルの圧縮
- エンドユーザーに配信するサイズを小さくするため圧縮する
プラットフォームごとのパッケージ化
- プラットフォームごとの専用ツールを使って専用のパッケージ化する

BuildFarmについて

以下から構成されるパッケージ作成高速化のためのオンプレ環境

ビルド用WorkStation
アセット高速取得用Helix Proxy Server
管理用Jenkins Server
Build Tool
執務室内にマシン置き場を作って設置した
- 室内は気温が高く、送風機による冷却を行っていた
BuildFarmでのパッケージ作成フローと所要時間
- エンジン取得　20min
- アセット取得　40〜60min
- Re engine 上でパッケージ作成　4〜10h
- 作成したパッケージのアップロード　20min
クライアントでビルドする場合に比べて大幅に速度向上ができた

Build Farmの課題点と解決策としてのクラウド

管理コストが高い
- 機材のフリーズや意図しない再起動、処理負荷増、熱によるクラッシュ
- 都度対応コストが発生した
スペースの問題
- 電源の問題
- ワークステーションを使っていた
- 設置スペースがなくなった
- 設置する際に電源工事が必要で、場所をかえれなくなった
障害発生時
- 社内のメンテナンスや法令停電の影響を受け、ビルドできなくなる

開発環境をクラウドに持っていけないか？
- 開発ピーク時のパッケージ作成数莫大化への対応
  - 週2回、51個のパッケージ作成
  - 開発ピーク時にはDLC対応も含めて週間の作成数が3倍になった
  - クラウドを活用することで、開発ピーク時の需要差（通常時、最大時）大きな差をカバーすることができる
- パッケージ作成環境の強靭化
  - オンプレからクラウドへの完全以降ではなく、併用する（ハイブリット化）
  - 異なる環境を併用することで、障害に強い開発環境の確保（対障害性の強化）

クラウド上へのBuild Farm環境の構築

AWS上にBuild Farm環境を構築し、検証を進めた

EC2上、AWS上でのRE ENGINEの動作検証
- AWS上から社内各種サービスとの連携確認
既存のBuildFarmとの連携作業
- Toolの改良
- EC2Pluginの改良
- パッケージ作成の高速化検証
- ここが１番時間がかかった
タイトルのテストパッケージ作成検証
構成
- 社内端末のBuild Toolからから社内のJenkinsに処理を投げる
- クラウドで処理する場合、AWS上に構築されたEC2上のJenkinsが受け取り、ビルドが走る
- 社内のNASにデータを返す
検証の結果
- AWS上でのパッケージ作成を実現することができた
- バイオハザードプロジェクトで実際に検証した結果、合計で３００個ほどのパッケージ作成をクラウド上で実施した
- オンプレとクラウドのハイブリット運用により、当初の課題の解決を行うことができた。

よかったこと

好きなだけスケールできる
- 実行イメージさえ作ってしまえば制限なく作成が行える
機材管理のコスト低下
- ソフトウェアのアップデート、環境更新の際でも１つのイメージを更新するだけで住む
- 作業時間が大幅に低減
- 経年劣化がないため、作成環境が安定した
AWSのエコシステムの活用
- 必要に応じてAWSの持つ様々なサービス（S3やLambdaといったAWSの仕組み）を使うことができた。

デメリット

利用料金
- パッケージ作成は時間がかかる（＝EC2の起動時間がかかる）ため、費用がかさみがち
- １パッケージ$27ほどかかった。
- 2022年は円安の影響があり、結果的に当初計画予算から比べて1.5倍のコスト増であった
- 開発ピークは2022年9月頃、まさに円安の真っ只中
  - ゲームは輸出産業であり、社内的に円安は為替差益を生むのでハッピーだったが、担当プロジェクトメンバーは悲しい気持ちだった
パフォーマンス差
- インスタンスの高速性よりも並列性の強化に振ったため、単体の作成速度はオンプレが上回った
- またAWSからのデータ転送の都合もあり大容量のデータ転送は社内ネットワークのが早かった
- まだまだ最適化の余地があると感じている
セキュリティに関するケア
- データの大量作成、破棄を繰り返す試みは社内でも初めてのことだった

今後の展望

VisualStudio AMIを利用したマルチプラットフォーム環境の構築をさらに推進
コンソール系ハードウェアへの対応を目指す
タイトル向けサービスの強化
- 社内全てのタイトルをいつでもパッケージ作成できるようにする
- 環境構築の容易化
- 作成の最適化

ほかの検証

パッケージ作成以外にも以下の検証を行っている

複数人プレイタイトルに向けたマルチプレイ環境の検証環境の構築
- 1台のPCに複数環境を起動してチェックするのは、現状のタイトルの負荷を考えると非常に難しい。チェック用に個人個人にサブPCを配布する？限界がある
- 簡易に利用してもらうためにAWS上にインスタンスを容易することを検討
外部協力会社向け環境の構築
- RE ENGINE環境をクラウド上に構築し、外部協力会社に提供
- 共同開発をより簡易に、よりセキュアに行うための検証を行っている